Compatibility tests#1788
Conversation
g1itch
added
enhancement
|
And of course the check's gonna fail. |
g1itch
force-pushed
the
compatibility
branch
2 times, most recently
from
ab52048 to
321d234
Compare
It's even worse: apparently the |
solved it in the recent code: https://github.com/g1itch/PyBitmessage/runs/3182720003#step:8:70 |
g1itch
force-pushed
the
compatibility
branch
2 times, most recently
from
0c2f1b6 to
4448900
Compare
g1itch
force-pushed
the
compatibility
branch
4 times, most recently
from
5982784 to
6f4eb38
Compare
g1itch
force-pushed
the
compatibility
branch
3 times, most recently
from
0f5c0cd to
ba9ec7c
Compare
g1itch
force-pushed
the
compatibility
branch
2 times, most recently
from
fbb6409 to
fe691a5
Compare
g1itch
force-pushed
the
compatibility
branch
from
7e3eed7 to
f9d3aa6
Compare
g1itch
force-pushed
the
compatibility
branch
from
f9d3aa6 to
a3a45a1
Compare
|
Maybe this shouldn't be called "Compatiblity tests" as most of it is network subsystem refactoring. Could you perhaps put the (smaller) protocol refactoring into a separate PR, and just keep this for the network subsystem? Then the protocol refactoring can be merged earlier and faster. |
|
maybe also "random" refactoring separately. |
I see, the rest of this branch is currently a complicated changeset merged from different branches with pretty controversial changes mixed with a few tests. I'm slowly reading the other part of the implementation in search of a pieces, which I can isolate clearly and cover by tests. Unsuccessfully so far. Maybe I'll rebase the branch, if I found a way to write cleaner set of tests for the significant portion of the protocol. But the overall idea of those "Compatiblity tests" is covering the protocol structures, excluding those related to crypto operations (the #1796 part). |
Yes, the random is probably closer to the refactoring of the crypto operations. But this particular approach is a bit problematic, so I don't merge those changes into the crypto branch and so far neither I see a way to isolate the related changes into a separate PR. So I'm going to rename the branch and replace it by the further changes when they are ready. |
2 participants
Hello!
Let's introduce some simple compatibility tests, based on a sample data and well known values. I wish them to cover the implementations of all the functionality, defined in the protocol. So that an alternative implementation can take the samples to check it's compatibility.
It's also helpful for the ongoing python3 porting. Because most of the developers are not writing any tests. And I've already found a feature in
highlevelcryptomodule, which I don't yet understand, but I think that such incompatibilities is better to reveal soon. The test shows that not all the subset ofpyellipticis used inhighlevelcryptoin compatible way with python3.